Alternatives for Macintosh Eudora
To Rewrite, or not to Rewrite

Introduction
The release of Eudora 7.0 for Windows poses the question of when Eudora 7.0 for Macintosh will be released. It turns out that this is not an easy question to answer. This paper explores some of the ideas that went into planning for the next major release of Eudora for the Macintosh, and examines alternative evolutions for the application.

Background
Before we discuss the problems facing Macintosh Eudora, we should describe some of the design elements of the application, as we will refer to them frequently.

The Mailstore
Eudora’s mailstore was designed when there was very little memory or CPU power available. It used these resources carefully, and was therefore able to perform very well in such limited environments. The basic design is to minimize the amount of processing done on text before it is displayed to the user. Therefore, message text is decoded and transliterated, and attachments and other non-text content are decoded and removed to separate files. The message text itself is stored along with the text of other messages in a file called a mailbox. The same basic mailstore is used in Windows Eudora, though enough details are different that they are not binary-compatible.

Carbon
Eudora uses the Carbon framework for its filesystem access and user interface. This is an older Apple technology, and has been supplanted by Cocoa1 .

The Editor
Of central importance to an email program is the text engine used to display and compose email. Eudora has a custom text editor, that works quite well, but has limited capabilities. It certainly has not kept up with the times regarding HTML standards, especially in the area of table display. Unfortunately, tables are used as a page layout system for nearly all but the simplest HTML nowadays, so this lack is rather keenly felt by users.

The Problems
In the past, it’s been our policy to maintain rough feature parity between the platforms. This has meant releasing versions on both platforms with roughly the same features at roughly the same times. However, this was not done for Eudora 7.0. Below we will explore the problems facing Eudora on the Macintosh. Along the way, we’ll note which of them apply, and to what degree, to Eudora for Windows as well.

Spotlight
Spotlight is Apple’s indexing technology. It is the rough equivalent of the X1 indexing that is being used in Windows Eudora 7. (X1 does not have a Macintosh product.) Unfortunately, Spotlight’s indices have a minimum file-level granularity. Because Eudora stores multiple messages in a single file, Spotlight cannot tell which message a word appears in, only that it appears in a particular mailbox. This makes Spotlight useless for Eudora as it stands today.

Possible solutions for this issue are twofold:

S/MIME
S/MIME presents an interesting challenge to Eudora. Eudora has long had the capability to do encryption and decryption and handle digital signatures, via a plug-in architecture (EMSAPI). This architecture was necessary due to US government policy regarding encryption technology2 . It is probably no longer necessary, and a more integrated approach is a possibility.

The problem with the current EMSAPI implementation is that it makes dealing with encrypted mail very unpleasant. It is certainly adequate for a functional system, but it is manual, clumsy, and suboptimal, involving attachments and extra user operations. This is the path we took for Eudora 7.0 for Windows. It meets basic requirements, but we don’t expect a high level of user satisfaction if it is used extensively.

Possible solutions to this problem include:


HTML Handling
One of the biggest user complaints is the lack of sophisticated HTML handling in Eudora. Because we use our own engine and because that engine is severely limited, especially in the area of tables, Eudora’s HTML display can be primitive. This is generally not a problem for most interpersonal email, but it is a problem for much institutional and commercial email, which typically assumes full-blown, up-to-date HTML capabilities.

One obvious solution to this problem would be to use Apple’s HTML viewer/editor, WebKit. However, the problem with WebKit is that it is fundamentally a Cocoa technology. While Apple officially claims it can be used by a Carbon application, they privately admit that it works at best imperfectly in such an environment. While we have been assured by some at Apple that this will be improved, it is difficult to see that as likely, as there is great pressure from Apple for developers to use Cocoa rather than Carbon.

Windows Eudora faces this problem also, but only for email composition; for viewing, it uses Microsoft’s HTML engine.

So, what can we do?


Unicode & Non-Roman Languages
Another common complaint from our international users, and anyone who deals globally, is our lack of support for non-Roman languages. While Macintosh Eudora can display and edit anything it receives, much of its internal structure assumes one byte per character, which presents difficulties for such operations as spell-checking and URL recognition. Also, the current mailstore makes no provision for Unicode storage of outgoing mail, so even though mail can be edited, it cannot be saved and sent properly.

Possible solutions to this problem include:

Windows Eudora shares this problem to a great degree.

Intel Macintoshes
Apple’s transition to Intel hardware raises further difficulties for Eudora. Eudora is currently built with Codewarrior from MetroWerks, a Motorola company. CodeWarrior is not going to support the new machines. While the current version of Eudora will run under the PowerPC emulator (called Rosetta) on the Intel Macintoshes, it will suffer a performance penalty. Just as an added bonus, part of the Eudora development process involves an application which runs under the old Classic emulator, which is not supported at all on Intel Macintoshes.

The two potential solutions to this problem are:

Carbon Limitations
The Carbon framework Eudora uses is, as has been noted, an older Apple technology. While Apple claimes it has parity with Cocoa, in truth there are many capabilities under Cocoa that are either not available at all to Carbon applications, available only after delays for Carbon applications, or only imperfectly available to Carbon applications. We fear this situation will only worsen over time.

Possible solutions include:

Resource Limitations
The Macintosh market is of course limited compared to the Windows market. However, the complexity of Macintosh software is not so much less than the complexity of Windows software, and it is increasingly difficult to maintain feature parity without spending a disproportionate amount of money doing Macintosh development.

Windows Eudora and Macintosh Eudora are now two entirely different codebases with nearly no commonality. There is therefore little opportunity for work done on one platform to be used on the other; different data structures, languages, etc are used in each. Parallel teams are required for development.

A further complication here is that the data formats from both products are not binary-compatible, so there is no direct way to move data from one platform to another.

Possible solutions to this problem are:


The Way Forward
So, having laid out all of the above, how should we proceed? It seems clear that a rewrite of Eudora for the Macintosh would solve all of the problems above. However, it’s a big task, one we have always been reluctant to take on, necessitating as it would a long hiatus between releases. Our current feeling is that it would take approximately 2 man-years to have an acceptably functional rewritten Eudora of Macintosh. Is there any other way forward?

Let’s recap the issues here, and then see what life looks like if we take some of the non-rewrite paths.


Regarding Spotlight, I’m confident that if we wait long enough, Apple will overcome the single-file limitation. It is in fact possible that by the time we would be able to finish the rewrite, the limitation would have been lifted in any case. The S/MIME issue can be worked around in the short term by living with the clumsy EMSAPI, and in the longer term by smaller changes to the application’s calling of the EMSAPI or by internal S/MIME support, without radical changes to the mailstore. Unicode support certainly could be added to the current code without a rewrite, though much of the effort would involve things we would get “for free” from a Cocoa rewrite. There is simply no alternative to moving to XCode to address the Intel Macintoshes. That’s a substantial, but by no means impossible, task.

So much for the simple solutions. That leaves us with three things to solve: the limitations of Carbon, the limited resources for development, and HTML.

The only real long-term solution to the HTML problem is a new text engine, whether it be WebKit or Gecko or who knows what. Fitting any of it into the current Carbon application would not be an easy task. Fixing the table support in Eudora’s current editor would probably ease some people’s concerns for a while, to buy time for such integration. Or HTML support could be left incomplete, and the damage that would do to the market penetration of Eudora on the Macintosh accepted.

The issue of limited resources for Macintosh-only development will remain a significant one as long as the two codebases are separate. If there is organizational will and sufficient Windows revenue, one might choose simply to live with it.

Finally, I think it clear that Carbon will not be immediately eliminated. It was ported to the Intel Macintoshes, which is a good sign. Most importantly, it is used by both Adobe and Microsoft, so there are developers important to Apple who also rely on it. It will likely continue to work for at least two years, perhaps more.

How long would it take to bring Macintosh Eudora up to Windows Eudora 7 features? The biggest uncertainty here is Spotlight. Until the multiple-container Spotlight is released, it’s not possible to do indexed search. Laying that aside, I expect it would take 4-6 man-months of labor to bring Macintosh Eudora to feature parity with Windows Eudora.

In Conclusion
It remains my recommendation that the Cocoa rewrite is the best plan for Macintosh Eudora. It would set up a strong base for the future for both platforms, as the rewritten code will migrate to Windows as well. It would provide for binary compatibility between the products. However, if there is no stomach for the required investment, it would be possible to continue with Eudora on the Macintosh with a less radical philosophy.

1 Cocoa is really just tweaks on top of NeXTStep, which is older than Carbon, but I digress.

2 We really want to editorialize on this point, but we will refrain.

Alternatives for Macintosh Eudora #